Grouping payments and payment requests

ABSTRACT

In one embodiment, a method includes receiving, by a payment service system, an indication from a payment application executing on a first mobile device operated by a first user to send a request for a money transfer. The method includes identifying second users in proximity to the first user based on identifying information associated with each second user of the second users received by the first mobile device over a wireless connection established by the first mobile device with each second mobile device. The method includes selecting one or more second users based at least on a contextual relationship between the first user and each second user of the one or more second users based on contextual information accessed by the payment service system or received from the first mobile device. The method includes causing each selected second user to receive the request for the money transfer.

PRIORITY

This application is a continuation under 35 U.S.C. § 120 of U.S. patentapplication Ser. No. 14/664,775, filed 20 Mar. 2015, now U.S. Pat. No.11,042,863.

BACKGROUND

Users are now able to conduct payment transactions, includingperson-to-person money transfer transactions, using applications ontheir mobile computing devices (“mobile devices”), e.g., “smartphones.”Some of these existing applications provide a “pay nearby” feature toenable a sender to send money to or request money from a contact who isnearby or in close proximity to the sender (e.g., within a distance offew meters). When money is to be sent or requested from a large numberof people, these existing applications generally require the sender tomanually input or select recipients one by one. As an example, whenmultiple people dine together, one person may pay the bill, but mayrequest the other diners in the group to pay their portion of the bill.As another example, one person may need to pay multiple nearby people,e.g., for completing an assigned task for which they are owed someremuneration. The process for identifying multiple people in a group andeither requesting or transmitting a payment can become cumbersome andtime consuming, e.g., when there are multiple people to be identified.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed technology for identifying nearby users that are likely tobe the intended recipients and sending a group payment or group requestfor payment to those nearby users to effect multiple money transfertransactions (hereinafter “group money transfer technology”) introducedhere may be better understood by referring to the following DetailedDescription in conjunction with the accompanying drawings, in which likereference numerals indicate identical or functionally similar elements.

FIG. 1 is a block diagram illustrating a network-based environment inwhich the group money transfer technology can operate.

FIG. 2 is a block diagram illustrating an example user interface of agroup payment request to be sent to multiple users detected as beingnearby a sender device and identified being among the contacts of asender.

FIG. 3 is a block diagram illustrating an example user interface of agroup payment request to be sent to multiple users detected as beingnearby a sender device and identified as being likely to be attending anevent with a sender based on schedule information.

FIG. 4 is a block diagram illustrating an example user interface of agroup payment to be sent from a sender device to other receiver devicesdetected as being nearby the sender device.

FIG. 5 is a block diagram illustrating an example group money transferflow involving a payment application in accordance with a firstembodiment of the group money transfer technology.

FIG. 6 is a block diagram illustrating a group money transfer flowinvolving a payment application and a geo-fenced area in accordance witha second embodiment of the group money transfer technology.

FIG. 7 is a block diagram illustrating a group money transfer flowinvolving a network operator and a geo-fenced area in accordance with athird embodiment of the group money transfer technology.

FIG. 8 is a block diagram illustrating example components of a clientdevice implementing the group money transfer technology.

FIG. 9 is a block diagram illustrating example components of a paymentservice system implementing the group money transfer technology.

FIG. 10 is a block diagram illustrating example method of generating andsending a group money transfer request to a payment service system.

FIG. 11 is a block diagram illustrating example method of processing agroup money transfer request by a payment service system.

FIG. 12 is a block diagram of an example of a computing system in whichat least some operations related to the group money transfer technologycan be implemented.

DETAILED DESCRIPTION

A group money transfer technology is disclosed for generating andsending a group payment or a request to a group for payment (eachhereinafter “a group request”) to multiple recipients (e.g., a “group”of recipients) who are nearby or in proximity to a sender of the grouprequest (“disclosed technology”). The group request when transmittedfrom the sender's device effects multiple money transfer transactionsinvolving financial accounts of the sender and the recipients.

In some embodiments, the disclosed technology enables a user (e.g., asender) to send an amount of money to or request an amount of money fromany number of individuals who are nearby (e.g., in proximity) to thesender using a single group request. For example, consider a holidayparty in a conference room in an office. Client devices of individualsin the conference room can “ping” each other to establish a connectionusing low energy wireless technology such as Bluetooth Low Energy (BLE)wireless technology, local Wi-Fi technology, or the like. A paymentapplication associated with a payment service system on any one clientdevice can exchange user identifying information with other clientdevices over, for example, the BLE connection. Thus, each paymentapplication can discover or identify other individuals that are nearby.Moreover, in some embodiments, the range over which a paymentapplication can exchange information with another payment applicationcan be user configurable. In the example above, an office manager canuse a payment application on his or her client device to input a fixedamount (e.g., $50) and select a group payment as a request type. Thepayment application then automatically identifies all individuals thatare in the conference room as recipients of the group request. When theoffice manager submits the group request using a single action, thesubmission of the group request causes funds to be transmitted from afinancial account associated with the office manager to financialaccounts of all the individuals present in the conference room, e.g.,$50 per individual in the group. Alternatively, the office manager mayselect a fixed amount (e.g., $50) to be shared among the individuals inthe group. In some embodiments, the amount that each individual wouldreceiver can be randomized. For example, one individual can receive $5,while another can receive $10. In yet other embodiments, one or morerestrictions can be placed on the number of individuals (e.g., 15individuals). If some of the individuals do not have a financial accountpre-registered with the payment service system, a notification can besent to those individuals to request financial account information forthe deposit. In this manner, the disclosed technology provides apractical solution to the problem of sending money to or requestingmoney from multiple individuals that are within a distance from eachother. Using the disclosed technology, the sender need not manuallyinput or select the names of individuals nearby. Moreover, in someembodiments, the sender can adjust the distance and thereby increase ordecrease the number of recipients that can be targeted by a single grouprequest. Use of the disclosed technology, thus, results in significanttime savings for the sender. Moreover, as the disclosed technology usesa single group request to trigger multiple money transfer transactions,the back and forth required to affect multiple money transfertransactions can be reduced and network resource usage can besignificantly reduced.

In some embodiments, the disclosed technology enables a sender to sendan amount of money to or request an amount of money from a group ofnearby individuals who are likely to be the intended recipients. Forexample, consider a scenario in which a group of five individuals are ina restaurant for dinner. The client devices of the five individuals canbe connected to each other using a low energy wireless technology suchas BLE wireless technology. Suppose one individual pays the bill, andthe rest need to pay the bill payer their share of the bill. The billpayer can launch a payment application associated with a payment servicesystem on his or her client device, select a group payment request asthe request type and input a fixed amount to be requested. The paymentapplication can then identify the four individuals, and possibly otherindividuals who are nearby the bill payer. The payment application canthen use contextual information, for example, contact information,schedule information (e.g., calendar events or appointments), socialnetwork posts, transaction history information, and/or the likeassociated with the bill payer to identify, from all the individualsthat are nearby, only those that are likely to be the intendedrecipients of the group request. In some embodiments, the contextualinformation describes a pre-existing relationship between the bill payerand the identified individuals. In this example, the payment applicationmay identify a calendar appointment at or near the time of request thatlists the four individuals as attendees. Based on this contextualinformation, the payment application can determine that the fourindividuals are the most likely candidates to receive the group request.A group request including identifiers associated with the identifiedrecipients and an amount can then be generated by the paymentapplication for sending by the bill payer. Once the group request issent, the payment service system sends each of the recipients identifiedin the group request a payment request for the specified amount. In someembodiments, the requestor can identifying variable amounts for eachindividual in the group, e.g., based on each individual's actualconsumption of food and beverages.

By using the disclosed technology to automatically identify the intendedrecipients of the group request based on location and contextualcriteria, the sender need not manually input recipient information, orperform bump or touch actions with devices of the recipients. With lesstime spent on data entry, money transfer transactions according to thedisclosed technology can be conducted in a fast and reliable manner.

In some embodiments, the disclosed technology enables sending of a grouprequest to any number of individuals in a geo-fenced area. For example,consider an event occurring at a neighborhood park. A virtual boundarycan be set up around the geo-graphical boundary of the park to form ageo-fenced area. The event organizer, via a payment application or aweb-based interface, can input a fixed amount (e.g., $5), specify thegroup request as a group payment request and send the group request sothat everyone who is within the geo-fenced area receives a notificationto donate the requested amount of $5. In some embodiments, locationmonitoring to detect a device entering or exiting the geo-fenced areacan be performed client-side. This enables everyone who is in thegeo-fenced area at a certain time to be automatically prompted with arequest to donate $5 by payment applications on their client devices.Alternatively, an individual can be prompted with a request to donate $5immediately upon entering or exiting from the geo-fenced area. In otherembodiments, a telecom network operator can perform the locationmonitoring to identify subscribers that are in the geo-fenced area, orsubscribers that have entered or exited the geo-fenced area. The telecomnetwork operator can then send a notification, via a text message (e.g.,SMS, MMS) to each identified subscriber to donate $5.

Sending a group request in this manner thus allows a sender to collectmoney from or distribute money to a large number of individuals, withouthaving to contact each individual separately. Moreover, in someembodiments, the individuals need not be users registered with a paymentservice system or have a payment application installed on their mobiledevices to receive the group request. Individuals having an account withthe payment service system but no payment application can reply to thetext message to donate the amount. Similarly, individuals that do nothave an account and do not have a payment application can providepayment details in reply to the text message or on a web-based interfaceto donate the amount.

In some embodiments, the disclosed technology can pre-generate a grouprequest for a sender to send when one or more conditions are met. Thegroup request can be pre-generated without receiving an explicitindication from the sender. For example, suppose a user pays $60 for acab ride with two of his friends using an application associated with apayment service system or a third-party application affiliated with thepayment service system. That transaction can trigger the paymentapplication or the payment service system to determine whether the useris with one or more companions (e.g., based on proximity, locationmonitoring and/or schedule information) and if so, to identify thosecompanions. The user can then be prompted to confirm whether a grouprequest for payment of a determined amount (e.g., $20 per person basedon the total transaction amount and the number of cab riders) is to besent to the identified companions. If the user confirms sending of thegroup request, the payment service system can process the group requestby sending to each of the two friends a payment request for $20.

Various embodiments and implementations of the disclosed technology willnow be described. The following description provides specific detailsfor a thorough understanding and an enabling description of theseimplementations. One skilled in the art will understand, however, thatthe disclosed system and methods may be practiced without many of thesedetails. Additionally, some well-known structures or functions may notbe shown or described in detail, so as to avoid unnecessarily obscuringthe relevant description of the various implementations. The terminologyused in the description presented below is intended to be interpreted inits broadest reasonable manner, even though it is being used inconjunction with a detailed description of certain specificimplementations of the disclosed technology.

FIG. 1 is a block diagram illustrating a network-based environment inwhich the group money transfer technology can operate. The environment100 can include multiple client devices 102-1, 102-N for sending andreceiving group payments and/or group payment requests. For example, theclient device 102-1 can be a sender device associated with a sender ofthe group request and the client device 102-N can be receiver deviceassociated with one of the receivers or recipients of the group request.The client devices 102-1, 102-N can be a desktop computer, a laptopcomputer, a mobile device, a tablet, or any other processing device. Themobile device can be, for example, a smart phone, a tablet computer, aphablet, a notebook computer, a wearable device, or any other form ofmobile processing device. In some embodiments, the client devices 102-1,. . . , 102-N can include a network interface based on Bluetoothtechnology (e.g., Bluetooth Low Energy or BLE) to enable the clientdevices to detect and establish a connection with other client deviceshaving a similar network interface that are nearby, and exchangeinformation over the established connection. In some embodiments, theclient devices 102-1, 102-N can include a payment application 120 thatinterfaces with the network interface and provides user identifyinginformation for exchange with the nearby client devices. Such useridentifying information that can be exchanged between nearby clientdevices can include, but is not limited to: a user identifier (e.g.,username or UID), an application identifier, a device identifier, aphone number, an email address, an alias, or any other information thatenables a payment application 120 of a client device to, directly or byquerying a remote server (e.g., payment service system 108), identify auser of a client device. The payment application 120 further enables asender to send a group request to multiple recipients who are detectedto be nearby, or match certain location and contextual criteria.

The environment 100 can also include other computer systems. Suchcomputer systems can include computer systems of the sender's issuingbank 118A and the receiver's issuing bank 118B. The issuing banks issuepayment cards (e.g., debit cards, credit cards, prepaid cards, giftcards, and so on). The sender has a sender financial account with thesender's issuing bank 118A and can use a payment card issued by thesender's issuing bank 118A to access the sender financial account todeposit or withdraw funds. Similarly, the receiver has a receiverfinancial account with the receiver's issuing bank 118B and can use apayment card issued by the receiver's issuing bank 118B to access thereceiver financial account to deposit or withdraw funds. The environment100 also includes a computer system of a card payment network(hereinafter “card payment network 116”) which can be a credit and/ordebit card processing network that handles authorization and settlementof transactions made using debit and/or credit cards.

The environment 100 also includes a computer system of a payment service(hereinafter “payment service system 108”) associated with the paymentapplication 120. The payment service system 108 facilitates electronictransfer of money from a sender's financial account to a receiver'sfinancial account. In order for the transfer of money to occur, thesender and the receiver each have a user account with the paymentservice system. The user account is associated with or linked to apayment card such as a debit card, a credit card, a prepaid card, or thelike. The payment service system 108 receives group requests (e.g., fromsender devices) to send a group payment or a group request for payment.Such group requests can be made using the payment application 120. Asender can specify an amount and select group payment or group requestfor payment as a request type using the payment application 120. Thepayment application 120 can then automatically generate an email messageor text message populated with the necessary information for sending bythe sender. For example, the “To” field of the email message can bepopulated with the email addresses of the recipients identified by thepayment application 120, the “Cc” field can be populated with an emailaddress associated with the payment service system 108 and the amount ofthe group request can be included in the body of the message. In otherembodiments, the payment application 120 can generate a text message oran HTTP request including the recipient information, the amount of thegroup request, and a type of the group request.

The payment service system 108 receives the email message (or textmessage or HTTP request) sent by the sender and parses the email messageto extract a sender email address of the sender, receiver emailaddresses of the receivers and the amount to be requested or sent. Ifthe email message is for sending a group payment request, the paymentservice system 108 can send an email message or a push notification toeach of the receiver email addresses to notify the receivers regardingthe sender's payment request. A receiver can then approve the request(e.g., via the email message, the push notification) to trigger thetransfer of the requested payment amount from the receiver's financialaccount to the sender's financial account.

If the email message is for sending a group payment, the payment servicesystem 108 generates and sends a payment request including the necessaryinformation (e.g., a payment amount, the sender's payment cardinformation, the receiver's payment card information) to the cardpayment network 116 (e.g., Star, NYCE or Pulse for debit card processingand Visa, MasterCard, etc., for debit/credit card processing) forauthorization and settlement. The card payment network 116 communicateswith the sender's issuing bank 118A and the receiver's issuing bank 118Bto facilitate the transfer of the payment amount. After the paymentrequest is approved, the sender's issuing bank 118A debits the sender'sfinancial account in real time. As a part of the settlement process, thepayment amount debited from the sender's financial account is sent tothe receiver's financial account and the receiver's financial account iscredited, thereby completing the transaction. Once the transaction iscompleted, a notification regarding the crediting or deposit of thepayment amount can be sent to the receivers (e.g., via an email message,a text message, a push notification).

In some embodiments, the environment 100 includes a third-party system,for example, a telecom network operator 110. The telecom networkoperator 110 can monitor location of its subscribers, and communicatewith the subscribers. The payment service system 108 can communicatewith the telecom network operator 110, via an application programinterface or other similar interface, to define a geo-fenced area andprovide contents of a message to be sent to subscribers if they aredetected in the geo-fenced area at a certain time, or once they aredetected entering or leaving the geo-fenced area.

Each of the aforementioned computer systems can include one or moredistinct physical computers and/or other processing devices which, inthe case of multiple devices, can be connected to each other through oneor more wired and/or wireless networks. All of the aforementioneddevices are coupled to each other through an internetwork 106, which canbe, or include, the Internet and one or more wired or wireless networks(e.g., a Wi-Fi network and/or a cellular telecommunications network).

The environment 100A can accommodate transactions involving paymentcards such as debit cards, credit cards, pre-paid cards, bank accounts,mobile payment applications and the like. The payment application 120can include an electronic wallet application, money transfer application(e.g., application for sending and requesting payments via email or textmessage), or any other application having an account that is linked toone or more payment cards and/or bank accounts and can be used by theowner of the client device to initiate transactions.

FIG. 2 is a block diagram illustrating an example user interface of agroup payment request to be sent to multiple users detected as beingnearby a sender device and identified being among the contacts of asender.

As illustrated, multiple client devices 102-1, 102-2, 102-3, 102-N areconnected to each other via the Bluetooth (e.g., BLE) interface 205. Insome embodiments, other low energy network interface can be used toestablish a connection between the client devices. Some of the clientdevices (e.g., client devices 102-1,102-2, 102-N) have a paymentapplication 120 associated with the payment service system 108, whileothers (e.g., client device 102-3) do not have the payment application12—installed on the client device. In response to an indication from asender of the sender device (i.e., client device 102-1) to initiate agroup request for payment, the payment application 120 generates a grouprequest for payment. The user interface 210 depicts the group requestfor payment generated by the payment application 120. The user interface210 can include, for example, an amount and a type of group request 215(e.g., $20 Request), a “To” field 220 populated with the recipients thatare identified by the payment application 120 as being the intendedrecipients of the group request, and a “For” field 225 for a reason forthe group request. In some embodiments, the user interface 210 can alsoinclude one or more filters 230 for selecting the recipients of thegroup request. For example, when the “all” filter is selected, thepayment application 120 identifies all users or client devices nearbythe sender device 102-1, some of who may not be known to the user of thesender device 102-1. When the “contacts” filter is selected, the paymentapplication 120 first identifies all users who are nearby, and thenapplies the “contacts” filter to select only those nearby users who arealso contacts of the sender. Thus, in the illustrated example, the fourlisted users are the contacts that are nearby the sender device 102-1.In some situations, the sender may wish to send the group request to thecontacts 235 and not the contact 240 who is also nearby. In suchsituation, the sender can de-select or uncheck the contact 240, whichcauses the “To” field 220 to be updated. The sender can then select the“Send” button to send the group request. In this manner, the paymentapplication 120 enables the sender to send a group request to multiple“contacts” nearby without having to look up and select each recipient,type the email addresses of each recipient, or send multiple requests.

FIG. 3 is a block diagram illustrating an example user interface of agroup payment request to be sent to multiple users detected as beingnearby a sender device and identified as being likely to be attending anevent with a sender based on schedule information.

In some embodiments, the sender can apply a “smart” filter from thefilter options 230 to identify recipients of the group request. The“smart” filter, in some embodiments, can be a combination of otherfilters that takes into account contextual information to identifymultiple recipients who are likely to be the intended recipients of thegroup request. The contextual information can include, for example,schedule information. Schedule information can be derived from calendarevents or appointments, social network posts, text messages, instantmessages, and/or the like. When the “smart” filter is selected, thepayment application 120 first identifies multiple users who are nearbythe sender. The payment application 120 then applies the “smart” filterto select, from the list of users, those users who meet one or morecriteria. For example, the “smart” filter can select those nearby userswho along with the sender are attendees in a calendar event. In FIG. 3,while only users 305 are in the sender's contact list, all four users(305 and 310) are nearby the sender and are attendees in the calendarevent. Thus the users 305 and 310 are identified as likely recipients ofthe group request and email addresses or other identifiers correspondingto the identified recipients are populated in the “To” field 245 of thegroup request.

FIG. 4 is a block diagram illustrating an example user interface of agroup payment to be sent from a sender device to other receiver devicesdetected as being nearby the sender device.

As illustrated, a sender device 102-1 has established a BLE connectionwith receiver devices 102-2, 102-3, . . . , 102-N. When a senderassociated with the sender device provides an indication to send a grouppayment, the payment application 120 in the sender device generates amessage (e.g., email message) for group payment that is at leastpartially prepopulated with an amount 410 specified by the sender andmultiple receivers that are likely to be the intended recipients of themessage for group payment in the “To” field 415. The sender can alsoinput a reason (e.g., “Bonus”) for the group payment in the “For” field420. In some embodiments, a restrictions field 425 may be available toimpose restrictions on the group request (e.g., maximum number ofreceivers, time of delivery, and/or the like). Also shown on the userinterface 405 is a list of receivers having receiver devices that thesender device 102-1 is connected to via BLE. In some embodiments, thesender can set up a filter 430 to select a subset of the nearbyreceivers. In the illustrated example, all nearby receivers are listed.When the “all” filter is selected, the payment application lists allnearby receivers, including receiver 435 who is in the sender's contactlist, receiver 440 who has previously engaged in a transaction with thesender and receivers 445 that the sender may or may not know. When thesender selects the send button, the payment application sends a grouppayment of $10 to the payment service system 108 and causes the paymentservice system to deposit $10 into the financial accounts associatedwith the receivers. The receiver devices that have the paymentapplications installed thereon can then receive a notification (e.g.,notification 450) from the payment service system 108 regarding thedeposit of the payment.

In some instances, a receiver device 102-3 may not have a paymentapplication 120 associated with the payment service system 108. Thepayment service system 108 can then send an email or text message (e.g.,message 455), if an email address or phone number corresponding to thereceiver device 102-3 available, to notify that the sender has sent apayment of $10 to the receiver. The receiver can either decline, ordeposit the payment into his or her bank account by providinginformation about the bank account or a payment card linked to the bankaccount.

In some instances, the receiver device 102-3 may not have a paymentapplication 120 and may not share a phone number or an email addresswith the sender. In such instances, the payment application 120 of thesender device can send a message directly to the receiver device 102-3over the BLE connection to notify the receiver device regarding thepayment, and instructions for declining or depositing the payment.

FIG. 5 is a block diagram illustrating an example group money transferflow involving a payment application in accordance with a firstembodiment of the group money transfer technology.

As illustrated, client device 102-1 is a sender device and clientdevices 102-2, 102-4, . . . , 102-N are receiver devices. In theillustrated embodiment, each of the sender and receiver devices have aBLE chip or device 205 that enables the devices to discover each otherand establish a BLE connection over which information (e.g., metadata)can be exchanged. Each of the sender and receiver devices can alsoinclude Wi-Fi and/or cellular (e.g., 3G, 4G, LTE) interfaces toestablish a second connection to the network 106 over whichcommunication with the payment service system 108 can occur.

The sender device 102-1 establishes a BLE connection with the receiverdevices 102-2, 102-4, . . . , 102-N by exchanging messages 510 inaccordance with the BLE protocol. The payment application 120 of thesender device exchanges information 515 with the payment applications120 of the connected receiver devices over the BLE connection. Theinformation 515 that is exchanged can include any user identifyinginformation, such as a username, an email address, a phone number, adevice identifier, an application identifier, and/or the like. Forexample, if device identifiers are exchanged between the sender andreceiver devices, the payment application of each device can query thepayment service system 108 to obtain a username or user profileinformation corresponding to the device identifier. The paymentapplication 120 can then generate a group request for payment (or agroup payment) directed to at least some of the receivers associatedwith the connected receiver devices. As described above, the receiverscan be selected by applying a suitable filter. The sender associatedwith the sender device 102-1 can cause the payment application 120 inthe sender device 102-1 to send the group request for payment 520 to thepayment service system 108 using a second interface 505 other than theBLE interface 205.

The payment service system 108 receives and analyzes the group requestfor payment 520 to determine or extract details of the group request.The payment service system 108 then sends a payment request 525 to eachreceiver device associated with receivers included in the group request.The payment applications of the receiver devices receive the paymentrequest 525 and can request the receivers to respond to the paymentrequest. In some embodiments, each payment application can generate anddisplay a notification (e.g., notification 550) to request the receiverto confirm or decline the payment request, or in some implementations,approve the payment request for a different amount. Each paymentapplication 120, upon receiving a response from the receiver, sends theresponse 528 to the payment service system 108 over the network 106. Thepayment service system 108, upon receiving responses approving thepayment request, exchanges messages 530 with the card payment network115 for authorization and settlement. The messages 530 cause a transferof the approved amount of funds from a financial account associated witheach receiver to a financial account associated with the sender. Thepayment service system 108 can also send a confirmation 540 to thesender to inform the sender of the status of the group request (e.g.,whether the transfer of funds has been initiated or completed, or whichof the receivers are yet to respond).

In some embodiments, the payment request to each receiver device can besent over the BLE connection, from the sender device. In suchembodiments, once the sender sends the group payment request, thepayment application generates, in the background, a message includingdetails of the payment request to the receiver devices. The paymentapplications in the receiver devices intercept the request and requestconfirmation from the receiver (e.g., via push notification 550). Thepayment applications on the receiver devices can then send theresponses, along with details of the request, to the payment servicesystem 108 for further processing. In this manner, even if the receiverand sender devices are offline (i.e., not connected to Wi-Fi or cellularnetwork), the sender can still send out the group request and thereceivers can still receive and take action on the requests, and thebackend processing of the group request/responses can occur once thereceiver devices are back online.

FIG. 6 is a block diagram illustrating a group money transfer flowinvolving a payment application and a geo-fenced area in accordance witha second embodiment of the group money transfer technology.

In some embodiments, a user can create a virtual boundary around areal-world geographical area to define a “geo-fenced” area and set up agroup payment or a group payment request for a specified amount to bedelivered to users who are in a geo-fenced area or who enter or exit thegeo-fenced area. In the embodiment illustrated in FIG. 6, the presenceof a client device in a geo-fenced area is detected client-side, by theclient device itself. For example, the client device can be listeningfor data packets transmitted by a beacon in the geo-fenced area (e.g.,using BLE technology). By way of another example, the client device canbe monitoring its own location and comparing the monitored locationagainst locations corresponding to a geo-fenced area.

Referring to FIG. 6, entry of a user 605 having a client device 602-1into a geo-fenced area 650 can be detected by a payment application 120on the client device 602-1 (610). In response, the payment application120 can trigger a message relating to the group payment or group paymentrequest corresponding to the geo-fenced area to be displayed on theclient device (615). In some embodiments, the group request can bedelivered to client devices having the payment application in advance.In other embodiments, the payment application can send a notification tothe payment service system 108 that the client device has entered thegeo-fenced area (620). In response, the payment service system 108 cansend a group request corresponding to the geo-fenced area to the paymentapplication (625). The message that is triggered can be, for example, apush notification (e.g., push notification 635) that providesinformation about the group request, and options for confirming orcanceling/ignoring the group request or confirming an amount other thanthe requested amount. Once the user 605 responds to the message, thepayment application can send the user response to the payment servicesystem 108 for processing (630).

FIG. 7 is a block diagram illustrating a group money transfer flowinvolving a telecom network operator and a geo-fenced in accordance witha third embodiment of the group money transfer technology. In thisembodiment, the location monitoring is performed by a telecom networkoperator 110 (e.g., AT&T, Verizon). Consequently, client devices neednot have a payment application installed thereon to receive a grouprequest.

Referring to FIG. 7, when a user 705-1 having a client device 702-1enters a geo-fenced area 750, a telecom network operator 110 can detectentry of the client device 702-1 into the geo-fenced area 750 (715). Thetelecom network operator 110 can then send a group request to the clientdevice 702-1 via a text message (720). In some embodiments, the telecomnetwork operator 110 can be configured to send a group request at apredefined time to all client devices (e.g., 702-1, 702-2) that arepresent in the geo-fenced area 750.

When the user 705-1 or 705-2 responds to the text message confirming therequest, the user response is sent to the telecom network operator 110(725). The telecom network operator 110 then forwards the user responseto the payment service system 108 for further processing (735).Alternatively, in some embodiments, the user can respond via an email,text message or via a payment application (if installed), and the userresponse can be sent to the payment service system 108 (730). Thepayment service system 108 can then send a confirmation message to theclient device 702-1 (740). In some embodiments, the confirmation messagecan include instructions for providing payment card details to enablethe payment service system 109 to deposit an amount corresponding to agroup payment to an account associated with the payment card or withdrawan amount corresponding to a group request for payment from the accountassociated with the payment card.

FIG. 8 is a block diagram illustrating example components of a clientdevice implementing the group money transfer technology.

The client device 102 includes a memory 804 for storing instructionsassociated with multiple modules of the payment application 120. In someembodiments, the payment application 120 can include a nearby useridentification module 825, a user filter module 830 having a schedulefilter 844, a contact filter 835, a transaction filter 840, a smartfilter 845, and/or a random filter 846, a group request processor 850, auser interface module 855, a geo-fence detector 860 and/or anotification module 865. One or more of these components or modules maybe optional in some embodiments.

The nearby user identification module 825 identifies multiple devices(and thereby individuals or users associated with the devices) that arenearby or in proximity to the client device 102. In some embodiments,the client device 102 can be considered to be nearby or in proximity ofanother device when the client device 102 has established a connectionwith the other device using a network interface such as a BLE networkinterface. A BLE connection can be established when two devices arewithin a pre-configured range. A typical BLE connection range is 20meters, but it is possible to extend this range to over 100 meters. Insome embodiments, the maximum range for the BLE connection can be set bythe payment application 120. Alternatively, the maximum range can beconfigured by a user (e.g., via the payment application 120 or via thedevice settings). In some embodiments, the nearby user identificationmodule 825 can consider another device as being near the client device102 when the two devices are connected to the same wireless (e.g.,Wi-Fi) network (e.g., same wireless access point) or the same cellularnetwork. In yet other embodiments, two devices can be considered to benearby one another if both devices are within a predefined geo-fencedarea (e.g., as detected by the geo-fence detector 860). Once aconnection with a nearby device has been established, the nearby useridentification module 825 can exchange information (e.g., useridentifying information, metadata) with the nearby device over theestablished connection.

In some embodiments, the user filter module 830 applies one or morefilters to select a subset of nearby users that match the filtercriteria as users that are likely to be the intended recipients of agroup request. The user filter module 830, in some embodiments, caninclude a contact filter 835, a transaction filter 840, a schedulefilter 844 and a smart filter 845. The contact filter 835, when applied,identifies nearby individuals that are also contacts of the sender. Thecontact filter 835 can access contact data stored in a local datastoreon the client device 102. The transaction filter 840, when applied,identifies nearby users with whom the sender has engaged in atransaction in the past or recently. The transaction filter 840 canaccess transaction history data stored in a local datastore on theclient device. The schedule filter 844, when applied, identifies nearbyusers that are attending the same event as the sender. The schedulefilter 844 can access schedule information derived from calendar data,social network posts, email, text messages, instant messages, and/or thelike. The schedule information can be gathered and stored at a localdatastore or cached on a local cache on the client device 102. In someembodiments, the user filter module 830 can include a random filter 846that randomly selects nearby users. The random filter 846 can be appliedon top of one or more other filters in some embodiments. In someembodiments, the random filter 846 can be configured with one or morerestrictions. Such restrictions can be on the number of recipients,maximum and/or minimum amounts, or the like. For example, for a grouppayment of a total of $20 to be distributed randomly among ten contactsnearby, the random filter 846 can select ten contacts at random, andassociate an amount to each contact, without exceeding the total valueof $20. The random filter 846 can then provide the selected contacts andthe associated amounts to the group request processor 850 to generate agroup request.

The group request processor 850 generates a group request for the senderto confirm or modify, and send. The group request processor 850, in someembodiments, receives an amount and a request type corresponding to thegroup request provided by the sender via a user interface (e.g.,generated by the user interface module 855). The group request processor850 communicates with the nearby user identification module 825 and/oruser filter module 830 to identify the intended recipients of the grouprequest. The group request processor 850 then generates the grouprequest that identifies or includes the recipients and the amount ofmoney. In some embodiments, the group request processor 850 can displaythe group request to the sender for confirmation or modification. Uponreceiving confirmation and/or modification (e.g., deletion or additionof one or more recipients) from the sender, the group request processor850 can send the group request. The sending of the group request causeseach of the recipients identified in the group request to receive apayment or a payment request for the amount of money. In someembodiments, the group request processor 850 can send the group requestto the payment service system 108 over the Internet (e.g., via Wi-Fi orcellular connection). In other embodiments, the group request processor850 can generate and send notifications, based on the group request,directly to the recipients' devices over the established connection(e.g., BLE connection). The notifications, depending on the requesttype, can request approval from each recipient to transfer an amount ofmoney specified in the group request from a financial account associatedwith the recipient to a financial account associated with the sender, ora notification of a transfer of the amount of money from the sender'sfinancial account to financial accounts associated with the recipients.

The geo-fence detector 860, in some embodiments, can monitor clientdevice 102 location against coordinates corresponding to one or moregeo-fenced areas to detect entry into, exit out of or presence of theclient device 102 in a geo-fenced area. The geo-fence detector 860 canthen trigger the payment application 120 (e.g., the notification module865) to display a notification corresponding to a group requestassociated with the geo-fenced area, in some embodiments. In otherembodiments, the geo-fence detector 860 can trigger a notification to besent to the payment service system 108 to report the presence of theclient device 102 in the geo-fenced area. The payment service system 108can then respond with a notification corresponding to a group requestassociated with the geo-fenced area.

The notification module 865 can generally handle generation and displayof any incoming and/or outgoing notifications such as pushnotifications, email, text messages, and/or the like. The networkinterface 870 can be a networking module that enables the paymentapplication 120 and the client device 102 to transmit and/or receivedata in a network with an entity that is external to the client device102 (e.g., other client devices, the payment service system 108),through any known and/or convenient communications protocol supported bythe client device 102 and the external entity. The network interface 870can include one or more of a network adaptor card, a wireless networkinterface card (e.g., SMS interface, Wi-Fi interface, interfaces forvarious generations of mobile communication standards including but notlimited to 1G, 2G, 3G, 3.5G, 4G, LTE, etc.), Bluetooth (e.g., BLE), arouter, an access point, a wireless router, a switch, a multilayerswitch, a protocol converter, a gateway, a bridge, bridge router, a hub,a digital media receiver, and/or a repeater.

FIG. 9 is a block diagram illustrating example components of a paymentservice system implementing the group money transfer technology.

In some embodiments, the payment service system 108 can include a useridentification module 910, a group request processor 915, a grouprequest pre-generator 925, and a geo-fence module 930. One or more ofthese components can access one or more database tables including atransaction history database table 950, a payment card database table955, and a user account database table 960 to retrieve data and/or storedata.

In some embodiments, the user identification module 910 can respond torequests from a payment application 120 to identify users. For example,device identifiers or aliases can be exchanged between two clientdevices upon establishing a BLE connection. The payment application 120in a client device 102 can then query the payment service system 108using a device identifier or an alias received from another clientdevice over the BLE connection. The user identification module 910 canrespond to the query by providing usernames and/or public profileinformation corresponding to the device identifier or alias to thepayment application 120. The user identification module 910 can accessdata from the user account database table 960, for example, to respondto the query requests for user identification.

The group request processor 915 handles group requests transmitted by asender. In some embodiments, the group request processor 915 receives agroup request and analyzes the group request to determine informationcontained in the group request. For example, the group request processor915 can determine recipients of the group request. Such recipients'devices may have been detected to be within a pre-configured vicinityrange of the sender's device using a low energy wireless technology suchas BLE wireless technology. In some embodiments, the recipientsthemselves may have matched one or more filter criteria related tocontact information, schedule information, transaction information, orthe like. The group request processor 915 can also determine an amountof money to be transferred and a request type indicating whether thegroup request is a group payment or a group request for payment of thedetermined amount of money. The group request processor 915 can furtherprocess the group request based on the request type. For example, whenthe request type is a group payment of an amount of money, the grouprequest processor 915 can query the user accounts database table 960 toidentify a financial account associated with the sender and financialaccounts associated with the multiple recipients. The group requestprocessor 915 can then initiate transfers of the amount of money fromthe financial account associated with the sender to the financialaccounts associated with the multiple recipients. Similarly, when therequest type is a group request for payment of the amount of money, thegroup request processor 915 can transmit notifications to the multiplerecipients to request approval of the group request for payment of theamount of money. Upon receiving responses from at least some of themultiple recipients approving the group request for payment of thedetermined amount of money or a different amount of money, the grouprequest processor 915 can initiate transfers of the approved amount ofmoney from financial accounts associated with the recipients to afinancial account associated with the sender.

In some embodiments, the group request pre-generator 925 canpre-generate a group request for a user to send when triggered by anevent and when one or more conditions are met. Examples of a triggerevent can include a transaction activity, a transaction activityexceeding a certain amount, type of merchant associated with atransaction activity, and/or the like. The one or more conditions can bebased on location monitoring, schedule information, and/or the like ofthe user and/or contacts of the user at the time of the transactionactivity. The group request pre-generator 925 can also send anotification to the user to confirm sending of the pre-generatedrequest. In some embodiments, the group request pre-generator 925 can beimplemented client-side.

In some embodiments, the geo-fence module 930 can enable a user toconfigure a geo-fenced area which can then be associated with a grouprequest. In some embodiments, the facilities of the geo-fence module 930can be accessed by users via a web-based user interface. The geo-fencemodule 930 enables a user to draw a boundary on a map, or providelatitude, longitude and a radius to define a geo-fenced area. In someembodiments, the user can set client side or remote location monitoringto detect entry or exit of a client device into or out of a geo-fencedarea. The user can also configure a transmission mechanism, timing andformat of the group request. For example, the user can configure a grouprequest to be transmitted by one or more telecom network operators, at12 pm, as a text message. This mechanism allows all users with devicesconnected to the telecom network operator's cellular network to receivethe group request as a text message. By way of another example, the usercan configure the group request to be sent to devices of users when theusers exit or enter the geo-fenced area. Data relating to geo-fences canbe stored in and accessed from the geo-fence database table 965.

FIG. 10 is a block diagram illustrating an example method of creatingand sending a group money transfer request to a payment service system.

The method starts when a payment application 120 on a client device 102receives a request or an indication from a sender to send a grouppayment or a group request for payment at block 1002. For example, insome embodiments, the sender can launch the payment application, selecta group payment or group request for payment as a request type andspecify an amount. The client device 102 can then establish a connectionwith nearby client devices at block 1005. In some embodiments, theclient device may already be connected to nearby client devices. Theconnection can be over an interface based on Bluetooth Low Energy (BLE)wireless technology, or other low energy wireless technologies. In someembodiments, the client device can use Wi-Fi technology to establish aconnection with nearby client devices. At block 1010, the paymentapplication 12—exchanges user identifying information with the nearbyclient devices over the connection. For example, the payment application120 can provide a username, an email address, a phone number, an alias,a device identifier, or the like associated with a user of the paymentapplication 120 to the connected client devices over the connection.Similarly, the payment application can receive similar user identifyinginformation from the nearby client devices over the connection. At block1015, the payment application 120 receives a filter selection foridentifying users that are likely to be the recipients of the grouprequest. In some embodiments, the payment application 120 canautomatically select a filter to be applied. If the selected filter typeis determined to be a “smart” filter at decision block 1020, the paymentapplication determines if schedule information is available at decisionblock 1035. If the schedule information is available, the paymentapplication 120, at block 1040, uses the schedule information toidentify multiple users from the all the users of nearby client devicesthat are likely to be recipients of the group payment or group requestfor payment. In some embodiments, the “smart” filter can use othercriteria in addition to schedule criteria to identify the intendedrecipients. If the selected filter type is “contact” at decision block1020, or if the schedule information is not available, the paymentapplication 120, at block 1045, identifies a list of nearby users thatare contacts of the sender or have recently engaged in a transactionwith the sender as likely to be the intended recipients of the grouprequest.

At block 1050, the payment application 120 displays the identified listof intended recipients for user modification and/or confirmation. Forexample, the sender can de-select or remove any user who should notreceive the group request, or add a user who should receive the grouprequest. At block 1055, the payment application 120 receives aconfirmation from the sender to send the group request. In response, thepayment application 120 transmits the group request to the confirmedlist of recipients at block 1060. In some embodiments, the group requestcan be sent directly to the nearby client devices of the confirmed listof recipients over the BLE connection. In other embodiments, the grouprequest can be sent to the payment service system 108 over a differentconnection (e.g., Wi-Fi or cellular connection). In this manner, thepayment application 120 enables the sender to send a group request tomultiple nearby users without having to type in their information orselect their usernames, with a single click or tap.

FIG. 11 is a block diagram illustrating an example method of processinga group money transfer request by a payment service system.

The method starts by the payment service system 108 receiving a grouprequest transmitted from a client device of a sender. The group requestis associated with a group payment or a group request for payment, andincludes information relating to the sender and multiple recipients,along with an amount. At decision block 1110, the payment service system108 determines whether the group request is a request for a payment or apayment. If it is a request for payment, for each recipient identifiedin the group request for payment, the payment service system 108generates and transmits a request for payment of an amount specified inthe group request at block 1115. At block 1125, the payment servicesystem 108 receives a response to the request for payment from therecipient. At decision block 1130, the payment service system 108determines whether the response approves the payment request. If so, thepayment service system 108 initiates a transfer of the specified amountfrom a financial account associated with the recipient to a financialaccount of the sender of the group request at block 1135. If not, thepayment service system 108 records the status of the payment request asdeclined or unapproved at block 1140. The payment service system 108 cansimilarly process any other responses to the payment requests that comein. The payment service system 108 can periodically (e.g., when all theexpected responses have been received, or after a time period havepassed) send a status report to the sender to provide information on thestatus of the response from each recipient of the group request at block1145.

At decision block 1110, if the type of group request is a group payment,the payment service system 108 initiates a transfer of an amountspecified in the group request from a financial account of the sender ofthe group request to a financial account of each recipient identified inthe group request at block 1150. At block 1155, the payment servicesystem 108 can generate and send a confirmation of completion of thegroup request for payment at block 1155.

FIG. 12 is a block diagram of an example of a computing system or aprocessing device 1200 in which at least some operations related to thegroup money transfer technology can be implemented. The processingdevice 1200 that can represent any of the devices described above, suchas the client devices 102 (e.g., sender device, receiver device), thesender's issuing bank 118A, the receiver's issuing bank 118B, thepayment service system 108 and the card payment network 116, and thetelecom network operator 110. As noted above, any of these systems mayinclude two or more processing devices such as represented in FIG. 12,which may be coupled to each other via a network or multiple networks.

In the illustrated embodiment, the processing system 1200 includes oneor more processors 1210, memory 1211, a communication device 1212, andone or more input/output (I/O) devices 1213, all coupled to each otherthrough an interconnect 1214. The interconnect 1214 may be or includeone or more conductive traces, buses, point-to-point connections,controllers, adapters and/or other conventional connection devices.

The processor(s) 1210 may be or include, for example, one or moregeneral-purpose programmable microprocessors, microcontrollers,application specific integrated circuits (ASICs), programmable gatearrays, or the like, or a combination of such devices. The processor(s)1210 control the overall operation of the processing device 1200.

Memory 1211 may be or include one or more physical storage devices,which may be in the form of random access memory (RAM), read-only memory(ROM) (which may be erasable and programmable), flash memory, miniaturehard disk drive, or other suitable type of storage device, or acombination of such devices. Memory 1211 may store data and instructionsthat configure the processor(s) 1210 to execute operations in accordancewith the embodiments of the technology described above. For example,instructions corresponding to the components of the client device 102illustrated in FIG. 8 can be stored in the memory 1211. Similarly, thecomponents the payment service system 108 illustrated in FIG. 9 can alsobe stored in the memory 1211.

The communication device 1212 may be or include, for example, anEthernet adapter, cable modem, Wi-Fi adapter, cellular transceiver,Bluetooth radio/transceiver (e.g., Bluetooth 4.0 or BLE), or the like,or a combination thereof. Depending on the specific nature and purposeof the processing device 1200, the I/O devices 1213 can include devicessuch as a display (which may be a touch screen display), audio speaker,keyboard, mouse or other pointing device, microphone, camera, etc.

Unless contrary to physical possibility, it is envisioned that (i) themethods/steps described above may be performed in any sequence and/or inany combination, and that (ii) the components of respective embodimentsmay be combined in any manner.

The disclosed technology introduced above can be implemented byprogrammable circuitry programmed/configured by software and/orfirmware, or entirely by special-purpose circuitry, or by a combinationof such forms. Such special-purpose circuitry (if any) can be in theform of, for example, one or more application-specific integratedcircuits (ASICs), programmable logic devices (PLDs), field-programmablegate arrays (FPGAs), etc.

Software or firmware to implement the technology introduced here may bestored on a machine-readable storage medium and may be executed by oneor more general-purpose or special-purpose programmable microprocessors.A “machine-readable medium”, as the term is used herein, includes anymechanism that can store information in a form accessible by a machine(a machine may be, for example, a computer, network device, cellularphone, personal digital assistant (PDA), manufacturing tool, any devicewith one or more processors, etc.). For example, a machine-accessiblemedium includes recordable/non-recordable media (e.g., read-only memory(ROM); random access memory (RAM); magnetic disk storage media; opticalstorage media; flash memory devices; etc.).

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the embodiments of thedisclosed technology. For example, the depicted flow charts may bealtered in a variety of ways. The order of the steps may be rearranged,steps may be performed in parallel, steps may be omitted, or other stepsmay be included. As another example, the actual implementation of thedatabase table may take a variety of forms, and the term “databasetable” is used herein in the generic sense to refer to any area thatallows data to be stored in a structured and accessible fashion usingsuch applications or constructs as databases, tables, linked lists,arrays, and so on. Similarly, any and all of the embodiments describedabove can be combined with each other, except to the extent that it maybe stated otherwise above or to the extent that any such embodimentsmight be mutually exclusive in function and/or structure. Thus, it isintended that the embodiments of the disclosed technology cover themodifications and variations of the disclosed technology provided theycome within the scope of the appended claims and their equivalents.

What is claimed is:
 1. A method comprising: receiving, by a paymentservice system, an indication from a payment application executing on afirst mobile device operated by a first user to send a request for amoney transfer; identifying, by the payment service system, a pluralityof second users in proximity to the first user based on identifyinginformation associated with each second user of the plurality of secondusers received by the first mobile device over a wireless connectionestablished by the first mobile device with each second mobile device ofa plurality of second mobile devices; selecting, by the payment servicesystem, one or more second users from the plurality of second usersbased at least on a contextual relationship between the first user andeach second user of the one or more second users based on contextualinformation stored by the payment service system or received by thepayment service system from the first mobile device; and causing, by thepayment service system, each selected second user to receive the requestfor the money transfer.
 2. The method of claim 1, further comprisingcausing the payment application executing on the first mobile device toestablish the wireless connection with each second mobile device of theplurality of second mobile devices using a first network interface. 3.The method of claim 2, wherein the first network interface is aBluetooth Low Energy wireless network interface and the wirelessconnection is a Bluetooth Low Energy wireless connection.
 4. The methodof claim 2, wherein the payment service system receives the indicationfrom the payment application via a second network interface of the firstmobile device.
 5. The method of claim 4, wherein the second networkinterface is a WiFi network interface or cellular network interface. 6.The method of claim 1, wherein the contextual information includes atransaction history associated with the first user indicating that thefirst user previously conducted a money transfer transaction with eachsecond user of the one or more second users.
 7. The method of claim 1,wherein the contextual information includes a list of identifiers forone or more second users received from the first mobile device, therebyrepresenting the first user having a pre-existing association with thesecond user.
 8. The method of claim 1, wherein the contextualinformation includes schedule information derived for the first userfrom calendar events or social network activities associated with thefirst mobile device, wherein the schedule information is usable toidentify one of the one or more second users as an attendee of an event.9. The method of claim 1, wherein the contextual information furtherincludes an indication that the first mobile device and each secondmobile device are located in a same geofenced area.
 10. The method ofclaim 1, wherein the contextual information further includes that thefirst user and each second user of the one or more selected second usersare tagged in a social network post.
 11. The method of claim 1, furthercomprising, prior to causing each selected second user to receive therequest for the money transfer, receiving, by the payment service systemfrom the payment application, a confirmation from the first user to sendthe request for the money transfer the one or more selected secondusers.
 12. The method of claim 1, further comprising generating, by thepayment service system, the request for the money transfer for eachselected second user comprising an identifier for a second mobile deviceof the selected second user, user identifying information for theselected second user, and the specified amount of money, wherein theidentifier for the second mobile device of the second user or the useridentifying information for the selected second user corresponds toinformation from a contact list associated with the first user.
 13. Themethod of claim 1, further comprising: receiving, by the payment servicesystem, a confirmation of the money transfer from at least one seconduser of the one or more selected second users; and transferring, by thepayment service system, an amount of money associated with the moneytransfer between a financial account associated with the first user anda financial account associated with the at least one selected seconduser.
 14. The method of claim 1, wherein the request for money transferis: a request for group payment, where the first user requests paymentfrom each selected second user; or a request for group transfer, wherethe first user requests payment to each selected second user.
 15. Themethod of claim 1, further comprising causing, by the payment servicesystem, the payment application to display a list of the selected secondusers recipient mobile devices for confirmation or modification by thefirst user.
 16. The method of claim 1, wherein the request for the moneytransfer received by each selected second user is received at the secondmobile device corresponding to the selected second user and includes acustomized message from the first user to the selected second user. 17.The method of claim 1, wherein each second mobile device is executing aninstance of the payment application, and wherein, when the paymentapplication executing on the first mobile device establishes thewireless connection with each second mobile device, the paymentapplication executing on the first mobile device exchanges theidentifying information with the instance of the payment applicationexecuting on each second mobile device.
 18. The method of claim 1,wherein causing one or more of the selected second users to receive therequest for the money transfer comprises causing the request for themoney transfer to be sent to the one or more second users via acommunication channel based on the identifying information associatedwith the one or more second users, respectively.
 19. A payment servicesystem comprising: one or more processors; and one or morecomputer-readable non-transitory storage media in communication with theone or more processors and comprising instructions that, when executedby the one or more processors, are configured to cause the paymentservice system to perform operations comprising: receiving, by thepayment service system, an indication from a payment applicationexecuting on a first mobile device operated by a first user to send arequest for a money transfer; identifying, by the payment servicesystem, a plurality of second users in proximity to the first user basedon identifying information associated with each second user of theplurality of second users received by the first mobile device over awireless connection established by the first mobile device with eachsecond mobile device of a plurality of second mobile devices; selecting,by the payment service system, one or more second users from theplurality of second users based at least on a contextual relationshipbetween the first user and each second user of the one or more secondusers based on contextual information stored by the payment servicesystem or received by the payment service system from the first mobiledevice; and causing, by the payment service system, each selected seconduser to receive the request for the money transfer.
 20. One or morecomputer-readable non-transitory storage media including instructionsthat, when executed by one or more processors of a payment servicesystem, are configured to cause the payment service system to performoperations comprising: receiving, by the payment service system, anindication from a payment application executing on a first mobile deviceoperated by a first user to send a request for a money transfer;identifying, by the payment service system, a plurality of second usersin proximity to the first user based on identifying informationassociated with each second user of the plurality of second usersreceived by the first mobile device over a wireless connectionestablished by the first mobile device with each second mobile device ofa plurality of second mobile devices; selecting, by the payment servicesystem, one or more second users from the plurality of second usersbased at least on a contextual relationship between the first user andeach second user of the one or more second users based on contextualinformation stored by the payment service system or received by thepayment service system from the first mobile device; and causing, by thepayment service system, each selected second user to receive the requestfor the money transfer.